|
|
|
|
|
|
|
Accepting Proposals from Third-Party Vendors Directly |
|
|
|
|
|
|
|
|
Third-party vendors, ever the capitalistic entrepreneurs, will gladly furnish you with testimonials, white papers, and magazine articles touting their products. Given this, you should use your best common sense when evaluating the role to be played by a control based on the proposals of third-party vendors alone. In the case of less known vendors offering a unique control that you need but can't find anywhere else, you must rely solely on the vendors documents and your thorough evaluation. |
|
|
|
|
|
|
|
|
Measuring Use Cases Against Proposals |
|
|
|
|
|
|
|
|
When you have all your proposals and related literature in hand, you should compare them against what role your use cases and interaction diagrams (sequence and collaboration) require. If the control doesn't have a well-defined role in your application, your investment in it is little more than a gamble. In fact, it might be a sign that the investment is based on successful marketing rather than need. Comparing the proposals against the use cases and scenarios is important because some of your developers might have a heavy bias for a particular control. This isn't necessarily bad, but the control must be justified objectively. |
|
|
|
|
|
|
|
|
Gray Box Versus Black Box Controls: The MicroHelp Problem |
|
|
|
|
|
|
|
|
Earlier in this lesson, I discussed the real risk that some vendors either take your money and run or simply go out of business through bankruptcy or declining market share. Of all the vendor failures in the history of third-party controls, none have been more infamous than MicroHelp. |
|
|
|
|
|
|
|
|
For those Visual Basic developers who don't remember MicroHelp, it was one of the more successful third-party vendors riding the wave of the rising third-party control market. Visual Basic developers came to rely on MicroHelp for valuable components to use in their applications. MicroHelp was the darling of the industry. |
|
|
|
|
|
|
|
|
For some unusually bizarre reasons, the third-party component operations of MicroHelp collapsed in 1996. MicroHelp stopped supporting its Visual Basic products. Developers and organizations scrambled for answers, and their technical support concerns went unanswered by the vendor. The third-party control market came under closer scrutiny by some organizations who were already weary of placing their trustand sometimes their companiesin the hands of third-party vendors. Some reports said that one of the heads of MicroHelp cashed out of the company to pursue personal or religious activities. |
|
|
|
|
|